Hello Kevin, [stuff deleted] > NCSA says that the util.c patch is enough to cover the vulnerability. > (their details are at http://hoohoo.ncsa.uiuc.edu/docs/patch_desc.htm) Be very careful with this one. The patch suggested by the NCSA merely fixes one single buffer overflow. There is at least one other overflow which is dangerous, and maybe there are even more, as was pointed out by several people on bugtraq. 'strsubfirst()' is not the only place. There is, e. g., the same problem with the 'strcpy(dname,&name[2])' in the function 'translate_name()'. Moreover, as Dan Thorson pointed out, there can be another buffer overflow, caused by the 'sprintf()' in the function 'log_transaction()' which prepends time and user info to the HTTP request. If you've only applied the patch by NCSA you're _still_ vulnerable. So instead of trying to fix all these routines, it might be wiser to fill the buffers with a limited number of characters initially. I've posted a suggestion for a bug fix to comp.security.unix to encourage review by a large audience. With the suggested fix he number of characters read by 'getline()' is limited to HUGE_STRING_LEN-100 (because of bugs like 'log_transaction()'). Moreover the URL part of the request is truncated to MAX_STRING_LEN-100 after being extracted from the request by 'getword()'. Thus you can prepend a document root of up to 100 characters without getting an overflow with all those 256 character buffers. This should fix the problems we've discovered up to now without wasting any memory. > The top of that page reads: > > A vulnerability was recently discovered in the NCSA httpd. A program > which will break into an HP system running the precompiled httpd has been > published, along with step by step instructions. > Three cheers for full disclosure.. it gets results. Yes, it's amazing how fast CIAC and CERT have been at publishing advisories. This might suggest, that they've been sitting on this info for quite a while, But then again, they'd have told us. Wouldn't they? :) Have a nice day, -Thomas -- Thomas Lopatic lopatic@informatik.uni-muenchen.de